home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr11 / adde13a.zip / ELUGUIDE.TXT < prev    next >
Text File  |  1993-06-26  |  10KB  |  182 lines
  1.  
  2.  
  3.  EchoList - The EchoMail Conference List                                Page 1
  4.  Users Guide                                                as of: 21 Feb 1993
  5.  
  6.  PURPOSE
  7.  
  8.  This Users Guide is intended as a brief overview of the EchoList, and a
  9.  shortcut description of how to submit updates to the database.  Probably 75%
  10.  of you will not need to know anything more about the process than what you
  11.  find here.
  12.  
  13.  The companion Technical Reference document goes into much more detail on the
  14.  format of the update messages and on how the EchoList system itself works.
  15.  Those of you with insomnia will want to take a look at it right away.
  16.  
  17.  The EchoList is a monthly publication which attempts to document certain
  18.  interesting information about EchoMail Conferences; "interesting" to people
  19.  who would like to participate, interesting to EchoMail Coordinators and those
  20.  who route the conference traffic, and potentially interesting to the
  21.  Conference Moderator.  The base product of the EchoList database is the
  22.  detailed Conference listing.  But, as needs are identified which can be
  23.  satisfied with the available information, additional reports and analyses can
  24.  be developed.
  25.  
  26.  Basically, the EchoList is maintained by the Moderators who choose to
  27.  advertise their conferences here.  Additions and updates to the database are
  28.  done by submitting NetMail messages addressed to a special name and node
  29.  address.  The Subject of the message indicates what is to be done, and the
  30.  body of the message has the data for the database entry, formatted one
  31.  keyword and value per line.  If you're familiar with AREAFIX or RAID message
  32.  formatting, this will give you no trouble.
  33.  
  34.  In order to keep the EchoList clear of out-of-date information and dead
  35.  conferences, all entries expire six months after initially published.  You
  36.  must send an update at least once every six months to maintain your EchoList
  37.  entry.  Let me repeat: YOU maintain the EchoList entries--not me.  I just
  38.  publish 'em.
  39.  
  40.  ADDITIONS AND UPDATES
  41.  
  42.  To add or update an EchoList entry, submit a NetMail message to "ECHOLIST" at
  43.  1:1/201.  The message subject must be "MOD UPD".  The body of the message
  44.  text has the data for database entry, formatted so that every line starts
  45.  with a special keyword that identifies the field name, followed by the data
  46.  to be put in that field.  Most of the lines are optional.  If you don't want
  47.  to supply data for a given field, don't include it in the message at all.
  48.  The only required fields are TAG, TITLE and MODERATOR.
  49.  
  50.  The first line describing a conference entry is TAG.  The other lines can
  51.  come in any order, but TAG must come first.  I'll list the keywords and flags
  52.  in a typical message followed by a brief description of each.  For a more
  53.  detailed description refer to the Technical Reference.  The CAPITALIZED part
  54.  of the keyword is the minimum abbreviation you can use.  The To-name,
  55.  subject, keywords and passwords are NOT case sensitive.
  56.  
  57.  To add or update an EchoList Entry send a NetMail message:
  58.  
  59.  To:       ECHOLIST
  60.  
  61.  Copyright (c) 1993 by Michael G. Fuchs
  62.  
  63.  EchoList - The EchoMail Conference List                                Page 2
  64.  Users Guide                                                as of: 21 Feb 1993
  65.  
  66.  At:       1:1/201
  67.  Subject:  MODerator UPDate
  68.  
  69.  In the body of the message:
  70.  
  71.      TAGname       <symbolic area name> /NOSHow
  72.      TITLe         <brief title for sorting>
  73.      DESCription   <A full description of the conference, audience, topics...>
  74.      MODerator     <moderator name>, <moderator node>
  75.      PASSword      <current password>, <new password>
  76.      TOTalnodes    <number of nodes carrying this conference>
  77.      VOLume        <number of messages>/<Month or Day or Week>
  78.      RESTrictions  /SYSop /MOD-apvl /MEMber
  79.      ORIGin        <origination node of the distribution
  80.      DISTribution  <distribution areas or vehicles of note>
  81.      GATEway       <gateways to other zones & networks crossed>
  82.      SEENby        <node list>
  83.      PATH          <node-pair list>
  84.      ---
  85.  
  86.  The TAG is obviously the one-word symbolic name used in distributing the
  87.  conference;  also called the AREA name or GROUP name.  If you are paranoid
  88.  about unauthorized links to a privately distributed conference, you can
  89.  follow the tagname with a space and /NOSHOW.  This will record the conference
  90.  appropriately but not include the tagname in reports (it'll say <hidden>).
  91.  
  92.  TITLE should be a one-line title for the conference, preferably 70 chars or
  93.  less, preferably starting with a word which will make finding it in a sorted
  94.  list sensible (avoid starting with A, An, The, ...).
  95.  
  96.  DESCRIPTION allows for a longer description of the conference, and you can
  97.  supply multiple DESC lines and they will be appended.  Don't bother trying
  98.  fancy formatting.  All the lines are combined and word-wrapped into a single
  99.  paragraph.
  100.  
  101.  Next to title, MODERATOR is one of the most important fields.  The EchoList
  102.  definition of a Moderator is someone with authority over the internal
  103.  operation of a conference, with the right to state the description and
  104.  policies within it.  You MUST list at least one Moderator in order to have a
  105.  valid EchoList entry.  You can list as many as you want.  Each Moderator line
  106.  consists of a first and last name followed by their Node Address.  You only
  107.  put ONE NAME AND ADDRESS PER LINE.  If you have more than one alias address,
  108.  and you feel it's absolutely essential you advertise them, enter multiple
  109.  MODERATOR lines with your name, but different addresses on each.  This is a
  110.  good time to explain how the EchoList stores Node Addresses.
  111.  
  112.  NODE ADDRESSES -- The EchoList supports "5-D" or "Domain" addressing
  113.  throughout--with a twist.  All places in the EchoList where you can use a
  114.  node address support the full notation:  zzz:ttt/nnn.ppp@ddddddd,  where zzz
  115.  is the zone number, ttt is the net, nnn is the node, ppp is the point (if
  116.  applicable), and ddd is the Domain.  Zone, net, node and point are each
  117.  integer fields.  Domain is a text field than cannot contain spaces.  There's
  118.  more detail on how defaults are handled in the Tech Ref.  The twist is that
  119.  the EchoList allows use of the Domain field by itself to specify non-FidoNet
  120.  
  121.  Copyright (c) 1993 by Michael G. Fuchs
  122.  
  123.  EchoList - The EchoMail Conference List                                Page 3
  124.  Users Guide                                                as of: 21 Feb 1993
  125.  
  126.  addresses.  Lets say, for example, you wanted to list your Compuserve user id
  127.  as an alternate address, you could enter:
  128.  
  129.       MOD  Mike Fuchs, 1:266/71@fidonet.org
  130.       MOD  Mike Fuchs, @CIS-72760.3326
  131.  
  132.  But who'd want to do that...  Ah well, it's a Lucky Strike extra I threw in
  133.  to the NODE_ADDRESS processing routines.
  134.  
  135.  The PASSWORD field is not required.  If you assign one, you must use it in
  136.  every change you make from then on, and it may protect your entry from
  137.  modification by someone else.  There are two password fields.  The first is
  138.  for the current password.  The second is for the new password to change it
  139.  to, if you want to change it.
  140.  
  141.  TOTALNODES is for publishing a rough estimate of the number of systems
  142.  participating in your conference.  It's optional.  If supplied, save the
  143.  editorials--it's just a single integer number.
  144.  
  145.  VOLUME is for advertising a rough estimate of the volume of messages to be
  146.  expected by those who link-in.  It's optional.  If specified it MUST be a
  147.  single integer number followed by a slash followed by either MONTH, WEEK or
  148.  DAY to identify the time period in which that number of messages flow.
  149.  
  150.  RESTRICTIONS is a shorthand reference to rules applied by the Moderator
  151.  concerning admission to the conference.  /SYSOP means only Sysops are allowed
  152.  to participate,  /MEMBER means you must be validated as a member of some
  153.  organization in order to participate (eg: MENSA), and /MOD-APVL means you can
  154.  not link in without specific approval of the Moderator.
  155.  
  156.  ORIGIN, DISTRIBUTION and GATEWAYS are just an organized set of text fields
  157.  you can use to describe sources and contacts that control links to the
  158.  conference.  Use none, any or all of them as you see fit.  If you are on a
  159.  formal distribution backbone of some kind, don't just say BACKBONE--there are
  160.  lots of them.  Specifically say "Zone 1 Backbone" or "Zone-3 Backbone" or
  161.  "EchoNet Backbone"...
  162.  
  163.  SEENBY lines let you document where your conference appears.  This is a total
  164.  waste of space for backbone-type conferences.  Saying you're on a backbone in
  165.  the DISTRIBUTION field above should be more than adequate.  If you use it for
  166.  a privately distributed conference, list the node numbers the way you'd see
  167.  them on an EchoMail message (except these can include Zone, Domain and
  168.  Point).  Like EchoMail seen-by lines, if you leave off the Domain, Zone or
  169.  Net, it'll be inherited from the previous seen-by node address.
  170.  
  171.  PATH lines let you document specific routing connections as pairs of
  172.  connected node addresses.  If you want to use these, look at the Tech Ref for
  173.  an explanation.
  174.  
  175.  That's a brief look.  There's a lot more detail in the Technical Reference.
  176.  And I haven't even discussed the KEY or OPTIONS lines.  And there are message
  177.  formats for deleting EchoList entries and for submitting Conference Rules
  178.  files for inclusion in a combined archive of rules.  You probably should,
  179.  eventually, look over the Tech Ref.  Enjoy.
  180.  
  181.  Copyright (c) 1993 by Michael G. Fuchs
  182.